Как вы знаете, в новой версии решения организации отказоустойчивых кластеров VMware vSAN 6.6 появилась возможность шифрования хранилищ. В целях увеличения эффективности и скорости работы в этой технологии используется концепция "encryption at rest". Сначала данные в незашифрованном виде идут по сети (в целях ускорения и работы сжатия), затем они в зашифрованном виде падают в кэш. После чего, перед тем, как отправиться на постоянное хранение (destaging), они будут расшифрованы, дедуплицированы/сжаты и снова зашифрованы уже на целевом устройстве.
Очевидно, что это удобно и эффективно с точки зрения экономии дискового пространства, но несколько небезопасно, так как из кэша можно потенциально достать незашифрованные данные. Поэтому и существует технология VM Encryption, лишенная этого недостатка, но неэффективно расходующая диск.
Для работы шифрования vSAN нужно, чтобы в кластере была версия on-disk format 5 или выше, при этом пятая версия появилась только в vSAN 6.6. Здесь возможны 3 сценария использования шифрования vSAN:
Развертывание кластера с нуля на vSAN 6.6.
Апгрейд кластера с vSAN 5.x./6.x на 6.6 со сменой on-disk format на версию 5.
Апгрейд кластера с vSAN 5.x./6.x на 6.6 без изменения версии on-disk format.
В первом случае шифрование данных можно будет включить сразу же для нужного хранилища. Это добавит специальный тэг в метаданные тома, после чего все новые данные, передаваемые из кэша на диск, будут зашифрованы.
Во втором случае мастер миграции может выполнить процедуру DFC (disk format change), что поменяет on-disk format на версию 5. Далее также можно будет включить шифрование в любой момент, и с этого момента новые данные тома будут шифроваться. При этом не потребуется убирать виртуальные машины с хранилища
Ну а вот в третьем случае (когда в процессе апгрейда вы не прошли процедуру DFC), понадобится переместить все виртуальные машины с нужного тома, чтобы включить на нем шифрование. Это может вызвать некоторые неудобства, поэтому лучше всего воспользоваться вариантом один или два.
Некоторые из вас знают, что известный блоггер Вильям Лам в числе прочего занимается виртуальным модулем Nested VMware ESXi, то есть готовой к импорту на ESXi виртуальной машиной с этим же гипервизором внутри. Это может пригодиться, например, для создания виртуальных тестовых лабораторий с несколькими гипервизорами на базе одного физического сервера.
Так вот недавно Вильям опубликовал в облаке Amazon S3 стороннюю библиотеку контента (Content Library), где выложены и будут обновляться виртуальные модули Nested VMware ESXi версий 6.x.
Для закачки контента библиотеки вам понадобится зайти в раздел Content Libraries в клиенте vSphere Client:
И далее нужно указать следующий URL подписки на контент:
После того, как библиотека добавится, вы увидите следующие 2 образа (как видно из скриншота выше, не обязательно скачивать их сразу, их можно загрузить по мере необходимости):
Первый - это виртуальный модуль ESXi 6.5d с поддержкой VMware vSAN, а второй - это ESXi 6.0 Update 3. Вещь полезная и удобная, а главное, что Вильям обещает обновлять данные образы.
Устанавливается он как Solution (расширение) в консоли vRealize Operations Manager:
Service Discovery Management Pack производит сбор информации о зависимостях между различными компонентами виртуальной инфраструктуры, как на уровне ее объектов, так и на уровне сервисов в рамках одной или нескольких виртуальных машин.
Делается это за счет агрегации полученных данных о сервисах в виртуальных машинах и анализа сетевой коммуникации между ними. Далее на основе полученных взаимосвязей можно динамически построить приложение как совокупность сервисов в разных ВМ.
Service Discovery Management Pack позволяет ответить на следующие вопросы:
Какие типы сервисов работают в виртуальной инфраструктуре (например, MySQL, Apache Tomcat и т.п.)
Какая виртуальная машина является составным компонентом приложения/сервиса
Каково будет последствие выключения или перемещения ВМ для приложения
Каковы будут последствия инцидента и путь экскалации проблемы по иерархии сервисов
Какие ВМ нужно переместить, чтобы переместить приложение целиком
Какие приложения будут затронуты в случае планового простоя или недоступности компонента виртуальной инфраструктуры
Как пользователи осведомлены о наличии в их инфраструктуре конкретного сервиса и приложения
Какие ВМ являются частью плана аварийного восстановления
Есть ли ВМ, которые нуждаются в защите с точки зрения восстановления на уровне площадок
Вот так выглядит окно информации о конкретной ВМ с точки зрения сервисов, которые в ней работают (обратите внимание, что в правом нижнем углу показана топология взаимосвязи для данной ВМ):
А вот так выглядят отношения сервисов, которые работают в разных ВМ, на уровне приложения, которое они составляют:
Скачать VMware vRealize Operations Service Discovery Management Pack можно по этой ссылке. Ну а вот еще несколько полезных ресурсов о продукте:
На днях компания VMware выпустила чуть обновленную версию своего продукта VMware vCloud Availability 1.0.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).
Сервис-провайдер, участвующий в программе vCloud Air Network (vCAN), предоставляет ресурсы своего облака как Disaster Recovery площадку на случай аварии в датацентре клиента.
Репликация данных виртуальных машин происходит с помощью виртуального модуля VMware vSphere Replication Appliance (VSRA), который развертывается только на стороне датацентра клиента. Технология vSphere Replication позволяет откидывать реплики виртуальных машин в удаленную инфраструктуру сервис-провайлера, при этом как только данные покидают хост VMware ESXi - они сразу же шифруются.
Таким образом, никто не получит доступ к вашим ВМ в удаленном датацентре:
Архитектура решения VMware vCloud Availability выглядит следующим образом:
Модуль vSphere Replication Appliance содержит в себе несколько компонентов, в частности vCloud Tunneling Agent (vCTA), который обеспечивает безопасное SSL-соединение с датацентром сервис-провайдера. На стороне же провайдера vCAN работают так называемые Cloud Proxy Cells, которые принимают данные и являются составляющей частью решения vCloud Director.
Также в составе vCD есть Hybrid DR API, через который происходит коммуникация с компонентом vSphere Replication Cloud Service (vRCS). vRCS предназначен для того, чтобы постоянно информировать vCloud Director о составе получаемой инфраструктуры клиента, конфигурациях виртуальных машин, а также их размещении в провайдерском датацентре. В этом случае VSRA делает все то же самое, что он и делал бы для инфраструктуры онпремизной репликации через vCenter.
Ну а на видео ниже можно узнать, как происходит развертывание решения VMware vCloud Air Disaster Recovery для инфраструктуры клиента, который настраивает соединение с инфраструктурой сервис-провайдера:
Вот тут детально рассказывается о предварительных требованиях для создания такой инфраструктуры аварийного восстановления:
Ну а здесь, собственно, мы можем посмотреть, как конфигурируется удаленный (резервный) сайт под восстановление инфраструктуры предприятия в случае аварии:
Таким вот образом настраивается репликация в VSRA:
А на последнем видео - показан тест восстановления инфраструктуры в облаке после сбоя в датацентре клиента:
Больше о продукте VMware vCloud Availability и решении vCloud Air Disaster Recovery можно узнать по этим ссылкам:
Компания VMware на днях объявила о выпуске обновленной версии решения для виртуализации и доставки корпоративных ПК предприятия - VMware Horizon 7.2 (она уже доступна для загрузки). Напомним, что прошла версия VMware Horizon 7.1 вышла в марте этого года, но всего за три месяца VMware успела уже выкатить обновление.
Давайте посмотрим на новые функции и улучшения VMware Horizon 7.2:
1. Новые возможности Horizon Connection Server.
Появился Horizon Help Desk Tool - его можно использовать для получения статуса сессий Horizon, а также для сообщения пользователями о своих проблемах с виртуальными ПК. Эту штуку уже долгое время ждали от VMware.
Выглядит это следующим образом:
Новая фича Recursive Unlock позволяет разлочить все удаленные сессии после того, как клиентская машина была разлочена.
Можно настроить политики Workspace ONE Access Policies
в Horizon Administrator таким образом, чтобы дать возможность пользователям логиниться через Workspace ONE для доступа к их опубликованным десктопам и приложениям.
Instant clone desktop pool наследует настройки видеопамяти, такие как количество мониторов и разрешение экрана от снапшота родительской ВМ на vCenter. Эти настройки можно задавать на уровне пула.
vGPU профиль для пула instant-clone выбирается автоматически, когда вы выбираете снапшот родительской ВМ с vCenter.
Можно повторно использовать аккаунты компьютеров в AD, когда имена виртуальных машин мгновенных клонов совпадают с существующими именами компьютеров в AD.
Мгновенные клоны теперь можно хранить на локальных датасторах.
Лимит сессий для модуля архитектуры Cloud Pod увеличился до 120 тысяч.
Глобальные разрешения Cloud Pod можно настроить в Horizon Administrator.
Теперь можно настроить фильтры LDAP URL для Connection Server, чтобы идентифицировать пользователей, у которых нет AD UPN.
Horizon 7 поддерживает до 4000 одновременных соединений на экземпляр Connection Server (прямые, PCoIP Secure Gateway и Blast Secure Gateway соединения).
Теперь можно использовать возможности шифрования vSAN для инсталляций Horizon 7.
Теперь можно использовать политики Smart Policies, чтобы контролировать поведение опубликованных приложений.
Можно добавить тэг пулу приложений.
Можно настроить опубликованное приложение таким образом, что оно будет запущено до того, как пользователь откроет приложение в Horizon Client.
Можно сделать rebuild для ВМ в пуле полных клонов десктопов, если вы хотите заменить машину на другую, но при этом сохранить имя виртуального ПК.
Теперь можно выбирать кластер Storage DRS в дополнении к возможности выбора отдельных датасторов для автоматического пула полных клонов.
При развертывании пула полных клонов можно повторно использовать существующие аккаунты машин.
2. Возможности Horizon Agent for Linux.
Linux-десктопы теперь поддерживают следующие возможности:
Client Drive Redirection (CDR)
USB Redirection
Аудио для HTML Access
Режим SSO для
RHEL 7 Workstation x64 и CentOS 7 x64
Режим
FIPS 140-2 для RHEL 6 x64 and RHEL 7 x64
Поддержка K Desktop Environment (KDE) на CentOS 6 x64 и RHEL 6 x64
Полная поддержка RHEL 6.9 x64 и CentOS 6.9 x64
3. Новые функции Horizon Agent.
Улучшился Skype for Business - теперь можно делать оптимизированные аудио и видеозвонки в
Skype for Business изнутри виртуального ПК без нагрузки на ВМ и сеть. Весь медиапоток обрабатывается на стороне клиентской машины, а не на стороне ВМ в датацентре.
4. Horizon GPO Bundle.
Файлы административных шаблонов ADM были полностью заменены на ADMX.
5. Возможности Horizon Client.
Для получения детальной информации об обновленных клиентах Horizon Client 4.5 можно посетить вот эту страницу.
6. Безопасность.
Появился новый вид защиты HTTP protection, который проверяет систему на соответствие стандартами CORS и CSP.
Horizon Agent and Horizon Client теперь поддерживают защиту Local Security Authority (LSA).
Полный список новых возможностей VMware Horizon 7.2 размещен тут. Загрузить решение можно по этой ссылке.
Не так давно мы писали о новой версии клиента для управления виртуальной инфраструктурой VMware vSphere Client 3.15 и забыли упомянуть, что тогда же вышла и обновленная версия клиента для управления отдельными хост-серверами - VMware ESXi Embedded Host Client 1.21. Напомним, что о прошлой версии Host Client 1.17 мы писали в марте этого года.
Посмотрим на новые возможности ESXi Embedded Host Client 1.21, которых не так уж и мало:
Возможность увеличить размер датастора путем увеличения размера существующего экстента за счет использования доступного пространства на этом LUN.
Был улучшен датастор браузер - теперь корректно обрабатываются операции копирования и перемещения при действиях с дисками VMDK.
Корректная обработка горячего изменения сетевых адаптеров ВМ с MAC-адресами, назначенными сервером vCenter. Это предотвращает перегенерацию MAC-адресов при изменении портгрупп.
При добавлении новых дисков их тип выставляется как "Thick", чтобы соответствовать поведению сервера vCenter в этом же рабочем процессе.
Обработка отсутствующих данных о сертификатах в разделе Host -> Manage -> Security -> Certificates.
В разделе изменения или добавления виртуального коммутатора vSwitch теперь есть данные о статусе и скорости соединения.
Имя ВМ теперь отображается в самом начале в заголовке консоли и на вкладках.
Улучшено изменение разрешения при вписывании консоли в текущее окно.
В Firefox в неактивных полях ввода текст теперь более читаемый.
Теперь демон hostd определяет имя файла создаваемых виртуальных дисков.
Теперь нет ограничения по числу дисков, которые могут быть у виртуальной машины.
Предотвращение замены регулярного выражения для неопределенного свойства OVA-модуля.
Добавлена поддержка добавления пермиссий для групп.
Исправлена ошибка для ситуации, когда диски ВМ размещались на некорректном датасторе.
Загрузить ESXi Embedded Host Client 1.21 в виде VIB-пакета можно по этой ссылке. Установить его очень просто - выполните следующую команду (VIB-файл должен лежать у вас по указанному пути):
esxcli software vib install -v /tmp/esxui.vib
Удаляется клиент вот таким образом:
esxcli software vib remove -n esx-ui
Список поддерживаемых браузеров на данный момент таков:
На днях мы писали о выходе новой версии основного средства для управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 6.6. Одновременно с этим релизом компания VMware также выпустила интегрированное с этой платформой средство VMware vRealize Log Insight 4.5, предоставляющее возможности анализа лог-файлов и поиска по ним. Напомним, что об одной из прошлых версий Log Insight мы писали вот тут.
Давайте посмотрим на новые возможности Log Insight 4.5:
1. Полная интеграция с vRealize Operations.
Прямой запуск дэшборда Log Insight из Operations
Прямой запуск в режиме Log Insight Interactive Analytics
Объектное управление лог-файлами
Управление алертами vRealize Operations Alerts
Теперь Log Insight можно использовать как средство самого глубокого анализа проблемы тогда, когда стандартные средства Operations уже не помогают. Консоль Log Insight (Dashboard View или Interactive View) откроется прямо в консоли Operations, поэтому дожим проблемы происходит из одной точки:
Объектное управление логами означает, что вы можете выбрать любой объект в Operations, два раза кликнуть на него, и вам откроется список логов, которые с ним связаны. Ну а если вы 2 раза кликните на vRealize Operations Alerts, то вам откроются лог-файлы, в которых эти алерты зафиксированы.
2. Новые возможности сервера.
Обновленный Log Insight RESTful API
Поддержка механизма vComprehensive Single Sign-On
Убрана нативная поддержка Active Directory, теперь все происходит через VMware Identity Manager (vIDM)
API для опроса срабатывания алерта и истории нотификаций
Возможность указания типа аутентификации Basic для webhooks
Поддержка RFC 6587
3. Улучшенные возможности агента.
Фича vAgent multi-destination
Отправка необработанного syslog'а на любой сервер
Возможность распарсить лог syslog'а, включая поля PRI, PROCID и MSGID, и отправить его на сервер
Поддержка символов подстановки (wildcards)
Скачать VMware Log Insight 4.5 можно по этой ссылке. Документация доступна тут, а вот тут находится сообщество Log Insight с массой полезной информации.
Компания VMware на днях обновила свое основное решение для управления и мониторинга виртуальной инфраструктуры vSphere - VMware vRealize Operations Manager 6.6 (vROPs). Напомним, что прошлая версия Operations Manager 6.5 вышла в марте этого года.
Посмотрим на новые возможности VMware vROPs 6.6:
1. Улучшения юзабилити и user experience
Новый интерфейс на базе HTML5
Дэшборд Getting Started для быстрой навигации по задачам
Дэшборды для пользователей, разделенные на категории: Operations, Capacity and Utilization, Performance Troubleshooting, Workload Balance, а также Configuration and Compliance
Интеграция с решениями vSAN and vRealize Automation
Кстати, видео о новых дэшбордах vROPs можно посмотреть вот тут.
2. Нативные возможности управления кластерами vSAN
Централизованное управление растянутыми кластерами (stretched clusters)
Возможность полного управления решением vSAN, включая производительность, емкости хранения, логи, конфигурация платформы и ее состояние
3. Полностью автоматизированная балансировка рабочих нагрузок
Балансировка систем по производительности на уровне датацентра между кластерами и хранилищами
Учет DRS-конфигураций и предоставление возможности установки уровня автоматизации DRS для отдельных объектов
Механизм Predictive DRS
для предотвращения затыков производительности
Учет исторических данных для первоначального размещения виртуальных машин
На днях компания VMware обновила свой главный клиент для управления виртуальной инфраструктурой до версии VMware vSphere Client 3.15 (напомним, что он построен на основе технологии HTML 5). Несмотря на то, что он еще много чего не умеет, в скором времени он заменит более медленный vSphere Web Client, работающий на базе старой технологии Adobe Air.
Последний раз мы писали о vSphere Client версии 3.13, поэтому приведем ниже основные возможности и улучшения последних двух версий клиента:
Создание виртуальной машины с прицеплением к ней существующего виртуального диска vmdk.
Создание ВМ с диском типа RDM.
Совместимость с политиками хранилищ (Storage Policies), в том числе поддержка политики удаления ВМ.
Ссылка "More info..." для VMware Tools на странице VM Summary.
Действие "Customize Guest OS" для виртуальной машины. Для этого действия добавлены валидация и проверка пермиссий для мастеров Clone/Deploy VM.
Нотификация для выполнения операций на одной или нескольких ВМ.
Добавлена строчка "Managed By" в описании, что показывает, что хост находится под управлением vSphere Client.
Создание ВМ с кастомной политикой управления питанием (Power Management, задается на странице Customize Hardware > VM Options).
Улучшена производительность основного дэшборда.
Скачать VMware vSphere Client 3.15 можно по этой ссылке.
В настройках сервера VMware vCenter можно устанавливать уровни сбора статистик, собираемых с различным интервалом и хранимых заданное время. Кроме того, можно устанавливать примерный размер виртуальной инфраструктуры в хост-серверах и виртуальных машинах, что позволит грубо оценить размер базы данных vCenter.
Зайдем в консоль vSphere Web Client, далее выберем на vCenter и идем на вкладку "Configure". В разделе Settings выбираем пункт "General" и нажимаем "Edit". Тут в разделе "Statistics" мы увидим вот такую картину:
Здесь мы видим 4 уровня статистик, которые отличаются, в первую очередь, интервалом сбора данных. Каждая из трех колонок - Interval Duration, Save For и Statistics Level - может быть изменена для соответствующего уровня.
Чем выше уровень Statistics Level, тем больше данных будет собираться. Всего тут четыре уровня, а на уровне 4 собираются самые детальные статистики (их надо использовать только для целей глубокой отладки, так как база данных vCenter будет очень быстро заполняться).
По умолчанию тут значения такие (для всех интервалов используется уровень детализации Level 1):
Данные, собираемые с интервалом 5 минут, хранятся в течение 1 дня.
Данные, собираемые с интервалом 30 минут, хранятся в течение 1 недели.
Данные, собираемые с интервалом 2 часа, хранятся в течение 1 месяца.
Данные, собираемые с интервалом 1 день, хранятся в течение 1 года.
Здесь все понятно. А правило тут простое: чем больше интервал, тем выше (цифра больше) уровень статистики нужно использовать (или тот же, что и для меньшего интервала). Например, можно поставить уровень 4 для интервала 1 день, 3 - для двух часов, 2 - для 30 минут и 1 - для 5 минут. Об этом говорит и официальная документация VMware:
The statistics level must be less than or equal to the statistics level that is set for the preceding statistics interval. This is a vCenter Server dependency.
Далее в этом окне мы видим возможность задания числа хостов и виртуальных машин в вашей инфраструктуре. В правой части "Estimated space required" можно увидеть результат задания значений - предполагаемый размер базы данных vCenter.
Компания VMware на днях выпустила обновленную версию платформы VMware vRealize Automation 7.3 (это бывший продукт Cloud Automation Center), в котором появилась масса новых возможностей. Несмотря на то, что это "dot-релиз", в продукте есть много всего интересного (особенно с момента выпуска vRealize Automation 7.1, о котором мы писали осенью прошлого года).
Давайте взглянем на новые возможности VMware vRealize Automation 7.3:
1. Enhanced API’s for Deploying, Upgrading and Migrating vRA - появился новый API для автоматизации развертывания, апгрейда и миграции решения vRA.
3. Audit Logging Framework - новый фреймворк для отслеживания и анализа пользовательской активности. Также появилась интеграция с решением vRealize Log Insight и другими syslog-решениями.
4. Integrated Health Service - теперь в административном интерфейсе доступна консоль Health Service, которая предоставляет сведения о состоянии компонентов vRA и vRO, а также генерирует отчеты по требованию или как запланированная задача. На картинке изображена конфигурация Health Service.
5. Parameterized Blueprints - теперь для машины можно определить ее условный размер (Small, Medium, Large, Maher), что влияет на политики сайзинга, рассчитываемого в решении.
6. Intelligent Workload Placement (WLP) - теперь решения vRA и vRealize Operations используются совместно для определения подходящего места размещения виртуальных машин в соответствии с требованиями к производительности.
7. Container Management - теперь технология VMware Integrated Containers (VIC) поддерживается из коробки, что позволяет добавлять и управлять инстансами VCH как обычными Docker-хостами. Также поддерживаются хранилища Docker Volumes и Docker Remote API 1.21.
8. Config Automation Framework - поддерживаются сторонние средства конфигурации ИТ-сред, такие как Puppet. Можно добавить Puppet-конфигурацию и перетащить ее на виртуальную машину в Blueprint-дизайнере.
9. Azure Public Cloud Service Design Enhancements - теперь для дизайнера сервисов Azure можно перемещать компоненты драг энд дропом, также появились и другие улучшения юзабилити.
10. On-Demand NAT Policy Enhancements - NSX - это теперь отдельный Endpoint (а не общая часть vSphere Endpoints). Для NAT-компонента был существенно улучшен механизм работы с правилами. Также появилась поддержка Infoblox для NAT.
11. On-Demand Load Balancer Enhancements - появились улучшенные контролы для балансировщика, а также стал удобнее механизм работы с политиками балансировки.
12. NSX Security Enhancements - появилась возможность выбора действия "Change Security" для изменения политики NSX.
Загрузить новую версию продукта VMware vRealize Automation 7.3 можно по этой ссылке. Release notes доступны тут.
Недавно компания VMware выпустила обновленную версию продукта User Environment Manager 9.2 (UEM), предназначенного для управления пользовательскими окружениями и настройками в рамках инфраструктуры виртуальных ПК VMware Horizon. Напомним, что о последней мажорной версии решения UEM 9.0 мы писали вот тут.
Не так давно VMware собрала в кучу видео о новых возможностях UEM 9.2, из которых можно понять, насколько продвинулся этот продукт в плане гибкости и улучшения user experience.
Первое - это технический обзор возможностей VMware User Environment Manager 9.2 Technical Overview (там рассказывается о том, как работает решение, и описывается его архитектура):
Далее уже видео непосредственно о новых возможностях UEM 9.2. В нем раскрывается описание двух основных новых фич - privilege elevation (запрос дополнительных привилегий у пользователя при запуске или установке приложений) и publisher-based rules (блокировка и разрешение приложений издателей). Это первая часть обзора новых возможностей:
Во второй части обзора рассказывается о новых переменных окружения, новых шаблонах конфигурационных файлов для лучшей персонализации настроек и некоторых других моментах:
Далее уже идет подробное видео об использовании механизма повышения привилегий для приложений, требующих повышенные привилегии для запуска, а также для установщиков приложений:
Следующее видео - о механизме блокировки приложений и разрешения их запуска от конкретного издателя на базе его сертификата:
Ну и заключительное видео - об использовании новых переменных окружения, в том числе для скриптов, автоматизирующих рутинные операции:
Скачать VMware User Environment Manager 9.2 можно уже сейчас по этой ссылке.
Многие пользователи виртуальной инфраструктуры VMware vSphere часто используют кастомизированные образы гипервизора VMware ESXi, который распространяется OEM-производителями оборудования, например, HP. Эти образы включают в себя специфические драйвера устройств, которые, зачастую, отсутствуют в стандартном комплекте поставки ESXi (это и понятно, так как нельзя поддерживать все устройства всех производителей в одном образе).
Между тем, многие администраторы обновляют такие образы достаточно редко - иногда по полгода ждут пока OEM-вендор выпустит очередную версию образа и накатывают его. Но ведь бывают критические обновления безопасности ESXi, которые нужно установить как можно скорее. Для этого нужно знать, как выглядит процедура обновления кастомного образа vSphere.
Во-первых, нужно понимать, что основные номера билдов и даты релиза гипервизора указаны в статье KB 2143832. А патчи в виде VIB-пакетов можно скачать с портала MyVMware здесь.
Во-вторых, есть утилита PowerCLI Image Builder (о ней мы писали вот тут), которая позволяет поддерживать актуальное состояние образа ESXi с точки зрения последних обновлений, но в то же время сохранять специфический контент кастомных образов.
Ну и, в-третьих, для тех, кто умеет пользоваться утилитой, есть простая команда, которая позволяет склонировать существующий профиль образа и обновить его пакеты, накатив последние патчи ESXi:
Также у VMware есть скрипты PowerCLI, которые демонстрируют более тонкий подход к обновлению образов ESXi. Но надо отметить, что они официально не поддерживаются со стороны техподдержки VMware.
Итак, первый скрипт - esxi-image-creator.ps1 - представляет собой обертку к Image Builder и дает некоторые дополнительные возможности, которые часто требуются для кастомных образов ESXi. Например, он позволяет монтировать depot-файлы и включать или исключать VIB-пакеты из состава образов. Также там есть такие расширенные настройки, как указание билдов по датам выпуска, а не по номерам и т.п. Итоговый образ можно собрать в формате ISO или ZIP.
Второй скрипт -
esxi-image-comparator.ps1 - показывает различия между двумя профилями образов ESXi. Эти различия можно показать в консоли или графическом интерфейсе, а также экспортировать в CSV-файл для последующего анализа.
Как видно из картинки, в процессе работы скрипта можно в интерактивном режиме включать или исключать профили для сравнения.
Вот пример использования утилиты при обновлении кастомного образа Cisco для ESXi 5.5 (обновление U3b от декабря 2015) с последними патчами VMware и обновленными драйверами Cisco для устройств enic и fnic. При этом исключается VIB-пакет tools-light для оптимизации использования с Auto Deploy:
Ну а вот так выглядит результат сравнения обновленного профиля с исходным:
Еще один пример - включение в образ Dell ESXi 6.0U3, который уже был обновлен Dell, патча patch 7a (5224934) с пакетами VIB для NSX и удаление VMware Tools для использования с Auto Deploy.
А вот пример генерации образа для HPE Proliant, содержащего последние обновления из репозитория HP, а также последние обновления оффлайн-бандла ESXi 6.5:
Надо отметить, что не следует использовать публичный репозиторий VMware image profile repository для создания кастомных образов, так как он содержит много различных версий и модификаций, что может привести к созданию образа, который невозможно будет использовать.
Но зато вот такая команда позволит сформировать таблицу с отличиями каждого из релизов VMware ESXi:
Мораль поста такова - нужно пользоваться, по-возможности, кастомными образами ESXi от OEM-производителей, но не забывать накатывать обновления (особенно security patches) от обычных образов VMware ESXi, создаваемых VMware.
William Lam рассказал интересную штуку - настройками клиента для управления хост-серверами VMware ESXi Embedded Host Client можно управлять через Advanced Settings. Имеются в виду те параметры, которые доступны в меню Settings на хосте:
Этими конфигурациями можно управлять через расширенные настройки (Advanced Settings), которые доступны в разделе "System" клиента. Для этого используется пространство UserVars:
Несмотря на префикс этих настроек, они применяются ко всему хосту в целом, а не на уровне пользователей ESXi. Также ими можно управлять через vSphere API или любой другой vSphere SDK/CLI (устанавливать, получать дефолтное значение, а также узнавать, не перекрыты ли они).
Вот, что значат эти строчки и их дефолтные параметры:
Настройка
Описание
Значение по умолчанию
UserVars.HostClientCEIPOptIn
Подписывать ли пользователей на программу CEIP (Customer Experience Improvement Program) для Host Client: 0 - спросить, 1 - да, 2 - нет.
0
UserVars.HostClientDefaultConsole
Тип дефолтной консоли Host Client.
webmks
UserVars.HostClientEnableMOTDNotification
Включать ли нотификацию MOTD (сообщение дня) при логине в Host Client.
1
UserVars.HostClientEnableVisualEffects
Нужны ли визуальные эффекты для Host Client.
1
UserVars.HostClientSessionTimeout
Деолтный таймаут сессии Host Client в секундах.
900
UserVars.HostClientShowOnlyRecentObjects
Показывать ли только последние используемые объекты Host Client или нет
1
UserVars.HostClientWelcomeMessage
Приветственное сообщение, показываемое при логине в Host Client
В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.
Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.
Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:
Настройка высокой доступности vSphere High Availability.
Конфигурация vSphere Distributed Switch для трафика vSAN.
Настройка vMotion для ВМ.
Позволит убедиться в том, что все доступные накопители используются для кластера.
Есть средства конфигурации хостового контроллера.
Есть необходимая версия микрокода (firmware) хостового контроллера.
Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.
Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):
Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:
Конечно же, необходима настройка vSphere HA/DRS:
Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:
Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.
Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client
Интересная штука была анонсирована в мае компанией VMware - сайт docs.vmware.com, на котором в организованном виде хранится информация о продуктах компании, рассортированная по продуктам, и с возможностью вменяемого поиска. Внизу также есть блочок с последними новостями в плане документации по продуктам и обучающими видеороликами.
Обратите внимание, что слева есть удобные фильтры, которые позволяют ограничить вывод нужной вам версией продукта, типом документа и т.п.:
Для каждого элемента (документа или статьи KB) показывается дата его обновления. Если мы откроем конкретную статью, то помимо самого контента, внизу будет полезный раздел Related Links, откуда можно накопать еще много всего интересного.
Каждую статью можно сохранить в собственную библиотеку, доступную для зарегистрированных аккаунтов. В этой библиотеке можно управлять сохраненными элементами, организовывать их и шарить для коллег.
Ну а вот официальный анонс бета-версии портала docs.vmware.com от его команды разработчиков:
Как знают некоторые администраторы VMware vSphere, среди интерфейсов vSphere API есть механизм взаимодействия с виртуальными машинами через VMware Tools, который называется VMware vSphere Guest API.
Утилита VMware Tools Client, написанная Pierre Laine, позволяет подключиться к виртуальной машине через этот интерфейс, загружать/скачивать с нее файлы и скрипты и исполнять их. Это может оказаться полезным, когда вы потеряли сетевой доступ к виртуальной машине (например, внутри гостевой ОС что-то отвалилось).
VMware Tools Client соединяется с сервером vCenter, получает его иерархию через vCenter Inventory Service, после чего можно работать с виртуальными машинами для следующих целей:
Выполнение в гостевой ОС отдельных команд (например, пинг из ВМ) или скриптов
Загрузка, сохранение и удаление скриптов на ВМ (а также любых других файлов)
Загрузка скрипта из файла
Утилита кроссплатформенная с интерфейсом на JavaFX, поэтому может быть запущена на Linux/Windows системах. Также она не требует установки. На данный момент она находится в бете версии 0.2. В составе идет база данных SQLLite, в которой хранятся логины/пароли от vCenter и виртуальных машин. Скачать VMware Tools Client можно по этой ссылке.
В свете последних событий, связанных с WannaCry ransomware, очень актуальным становится проверка наличия того или иного установленного патча (Patch/Hotfix/KB) внутри ОС виртуальных машин. Test-VMHotfix из моего PowerCLI Vi-Module модуля быстро и эффективно проверит все ваши ВМ. Пользоваться функцией проще простого, передайте в pipeline ВМ для проверки и шаблон названия патча в параметре -KB... Таги: VMware, PowerCLI, Security, vSphere, VMachines
Некоторые из вас знакомы с решением VMware NSX, представляющим собой комплексный продукт для виртуализации и агрегации сетей датацентра. На днях на сайте проекта VMware Labs появилось интересное средство Autopology, позволяющее в проектировать сети NSX с помощью визуального редактора:
Вот основные задачи, решаемые Autopology:
Интерфейс drag and drop для создания графического представления логических сетей датацентра.
Возможность создания копий секций сетевой топологии в один клик.
Возможность вернуться к нарисованной архитектуре сети впоследствии для сверки полученного результата.
Возможность перейти к интерфейсу NSX Manager для дальнейшей кастомизации логических сущностей сетевого взаимодействия в любой момент.
Возможность присоединения нескольких виртуальных машин к логическим сущностям. ВМ могут работать на базе гипервизора ESXi или KVM.
Особенно решение Autopology будет полезно для новичков, которые только приступили к настройке и конфигурации NSX (что очень непросто поначалу). Вот что даст администраторам эта новая утилита:
Единое представление логического дизайна сети, в отличие от нескольких представлений NSX.
Интеллектуальное выставление дефолтных настроек позволяет более правильно и унифицированно сконфигурировать сеть.
Можно быстро масштабировать сети в несколько кликов мыши.
Единый инвентарь для рабочих нагрузок на базе разных гипервизоров.
Представление вычислительных и сетевых ресурсов в едином пространстве.
Для работы с утилитой (запуска сервера) вам потребуется машина Ubuntu 16.04 со следующими предустановленными пакетами:
apt-get install python-pip
apt-get install python-libvirt
apt-get install libssl-dev
apt-get install python-dev
apt-get install libffi-dev
В качестве браузера можно использовать Chrome и Firefox. Скачать Autopology можно по этой ссылке. Будем надеяться, что такой удобный интерфейс появится в следующей версии VMware NSX.
Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.
Этот релиз для многих администраторов является важным событием, так как прошлый кастомизированный образ HPE Custom ESXi от ноября 2016 года содержал в себе некоторые проблемы, касающиеся драйверов и работы с хранилищами (в частности, наблюдалась низкая скорость записи на локальные диски). Возможно, в этом релизе данные проблемы решены, по крайней мере новый набор драйверов должен улучшить некоторые вещи.
HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:
Номера билдов и их содержимое приведены вот в этом документе HPE (там же есть ссылки на соответствующие драйвера и офлайн бандлы ESXi). Ну а руководство по кастомизированным билдам HPE Custom ESXi находится вот тут.
Очередная полезность обновилась на VMware Labs - на этот раз это оптимизированный под виртуальную среду и готовый к развертыванию образ виртуального десктопа Ubuntu OVA for Horizon. С помощью этого виртуального модуля VDI-администраторы могут быстро развернуть инфраструктуру виртуальных ПК на Linux-платформе, получив уже все необходимые настройки и оптимизации в рамках OVA-пакета.
Особенности средства Ubuntu OVA for Horizon:
Базовый образ Ubuntu версии 16.04.2 LTS.
Виртуальное аппаратное обеспечение VMware HW v11 (для работы требуется ESXi 6.0 U2+).
Дефолтные имя пользователя и пароль - viewadmin/viewadmin.
Виртуальная машина включает 2 скрипта: horizon-optimizer.sh, который конфигурирует машину в соответствии с лучшими практиками документации по Horizon 7, а также linux-agent-installer.sh, который помогает с установкой агента Horizon View Agent.
Дополнительные твики и приложения, которые могут пригодиться администраторам.
Из-за ограничений VMware агент пока не предустановлен в этот OVA-модуль, его надо скачать вручную и запустить linux-agent-installer.sh.
Виртуальный модуль OVA был протестирован с инфраструктурой Windows 2003, 2008, 2012 и совместим с Samba Domains.
Для работы модуля потребуется vSphere 6.0 U2 или более поздняя версия,
Horizon Connection Server 7.1 или более поздний, Horizon Client 4.4 или позднее.
Это уже версия 1.1 данного модуля (о первой версии мы писали вот тут). Вот что добавилось за последние 2 месяца:
Релиз только на основе оболочки MATE (GNOME больше не включают)
Увеличенная vRAM до 128 MB вместо Automatic по умолчанию
Удалено аудио-устройство (большинству не нужно)
Сетевая карта VMXNET3 по умолчанию
Обновленный репозиторий для open-vm-tools на Ubuntu repo
Добавлены зависимости Horizon 7.1 Agent
Обновленные пакеты зависимостей для Ubuntu 16.04 on Horizon 7.1
Обновлен установщик и ссылки для Horizon 7.1
Обновлены пакеты медиа-кодеков для Ubuntu 16.04
Обновлены пакеты MATE на Xenial
Более надежное присоединение к домену
Опциональная смена пароля
Опциональное задание таймзоны
Опционально ставятся десктоп-аддоны
Добавлены попытки повторного выполнения wget для конфиг-файлов smb и krb5
horizon-linux-installer.sh переименован в linux-agent-installer.sh
Скачать Ubuntu OVA for Horizon можно по этой ссылке.
Недавно на сайте проекта VMware Labs появилась интересная утилита - Host Profiles CLI. Она позволяет администраторам VMware vSphere из командной строки выполнять те операции, которые недоступны в графическом интерфейсе механизма настройки хостов ESXi Host Profiles или доступны ограниченно (без средств автоматизации). Особо стоит отметить возможность совместного использования механизмов Auto Deploy и Host Profiles CLI.
Напомним, что профили хостов (Host Profiles) - это средство конфигурации серверов ESXi таким образом, что единый "золотой" профиль применялся к всем хостам, настраивая их единообразно, что уменьшает риски ошибок конфигурации, а также улучшает управляемость/обслуживание инфраструктуры и ее безопасность.
С помощью Host Profiles CLI из командной строки можно делать следующее:
Кастомизация stateless-хостов Auto Deploy до их загрузки и присоединения к vCenter Server.
Импорт/экспорт профилей хостов из локальных файлов.
Привязка профиля к существующему кластеру.
Установка единого рутового пароля в профиле или настройка профиля таким образом, чтобы использовать уникальные пароли root для каждого из хостов.
Настройка системного кэша (stateless, cached или stateful install).
Просмотр всех профилей хостов, доступных на vCenter Server.
Напомним, что начиная с vSphere 6.5, для механизма Host Profiles можно указывать параметры кастомизации отдельных хостов (IP-адреса, пароли и прочее) в CSV-файле. Но это можно делать только для хостов, которые были уже добавлены в Inventory сервера vCenter. С помощью Host Profiles CLI можно сделать прекастомизацию хостов через файлы CSV, которые будут развернуты через Auto Deploy (то есть, самих хостов пока еще нет в vCenter).
Ну и вот так можно делать импорт и экспорт профилей хостов (не пытайтесь делать импорт профиля для окружения с другим оборудованием хост-серверов):
Также посредством Host Profiles CLI можно установить тип развертывания хостов через Auto Deploy - Stateless caching (когда хост в случае массового сбоя и недоступности PXE-сервисов грузится из локальной кэшированной копии) или Stateful install (когда хост грузится с диска и уже больше не зависит от Auto Deploy). Вот как это делается:
Чтобы сделать бэкап всего сервера VMware vCenter Server или VMware vCenter Server Appliance (vCSA), вы можете воспользоваться продуктом Veeam Backup and Replication, либо сделать резервную копию встроенными средствами (например, через Management Interface - VAMI). Но это забэкапит весь сервер в целом, а иногда требуется создать резервную копию только базы данных vPostgres, чтобы впоследствии можно было быстро восстановить ее.
Для решения этой задачи была сделана KB 2091961, в которой описываются методы бэкапа и восстановления БД vCenter и vCSA. Приведем их здесь вкратце.
Бэкап и восстановление БД VMware vCenter Server:
Резервное копирование:
Заходим как администратор на Windows-машину с vCenter и находим файл vcdb.properties в директории %VMWARE_CFG_DIR%\vmware-vpx\, далее открываем его в редакторе.
Находим там пароль пользователя БД vCenter и сохраняем его.
Скачиваем пакет windows_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
В командной строке идем в папку %VMWARE_CIS_HOME%\Python\ и запускаем сценарий backup_win.py, где вводим пароль для пользователя БД, сохраненный на шаге 2, и путь к каталогу бэкапа.
Например, если вы хотите захотите сделать бэкап в C:\backup_VCDB.bak, выполните следующую команду (s_PJmbGzC83QRYlp - это пароль):
Заходим под администратором на vCenter и останавливаем службы vCenter Server и VMware Content Library. Для этого:
Идем в Start > Administrative Tools > Services.
Нажимаем правой кнопкой на VMware VirtualCenter Server и выбираем Stop.
Нажимаем правой кнопкой на VMware Content Library Service и нажимаем Stop.
Открываем файл vcdb.properties в каталоге %VMWARE_CFG_DIR%\vmware-vpx\, находим там пароль пользователя БД vCenter и сохраняем его.
Скачиваем пакет windows_backup_restore.zip по ссылке в конце статьи VMware KB и распаковываем его.
В командной строке идем в папку %VMWARE_CIS_HOME%\Python\ и запускаем сценарий restore_win.py, где вводим пароль для пользователя БД, сохраненный на шаге 2, и путь к файлу бэкапа.
Если, например, вы сохранили бэкап в C:\backup_VCDB.bak, то выполните следующую команду (s_PJmbGzC83QRYlp - это пароль):
В начале мая компания VMware выпустила очередное обновление своего основного средства для управления инфраструктурой VMware vSphere - vSphere Client 3.13. Три недели назад мы писали о нововведениях версий 3.10 и 3.11, а сегодня расскажем о новых возможностях обновлений 3.12 и 3.13.
Давайте посмотрим, что нового в vSphere Client:
Перекрывающие настройки распределения вычислительной нагрузки (VDRS) и нагрузки на хранилища (SDRS) могут быть теперь заданы.
Для виртуальных машин появилась настройка кластеров непрерывной доступности Fault Tolerance.
Стали доступны возможности Cross vCenter Server vMotion.
В списке хостов можно выбрать столбец с версией ESXi (по умолчанию не выбран).
Версия виртуального модуля видна в меню Help -> About VMware vSphere.
Доступна настройка VM Compliance для механизма политик хранилищ (Storage Policies).
Для распределенного коммутатора появились возможности добавления хостов и управления ими.
Появилось действие Check Policy compliance для политик хранения машины (VM Storage Policy).
Возможность создания новой виртуальной машины с кастомными VMware Tools и опциями загрузки (устанавливаются на странице Customize Hardware > VM Options).
Улучшения для пользователей с ограниченными пермиссиями при конфигурации ВМ.
Загрузить VMware vSphere Client 3.13 можно по этой ссылке.
На сайте проекта VMware Labs появился интересный PowerCLI-скрипт vCenter Cluster Performance Tool, с помощью которого можно получить информацию о производительности кластера за счет агрегации данных, поступающих от хостов VMware ESXi.
Это уже вторая версия сценария, переработанная на базе механизма модулей PowerCLI 6.0 (ранее она была построена на снипетах).
Для работы сценария понадобится указать 2 следующих параметра:
Интервал от 20 до 300 секунд. По умолчанию это 20 секунд, что соответствует сбору статистики в близкому к реальном времени, а значение 300 даст пятиминутный интервал между сборами, чтобы не создавать лишнюю нагрузку.
Специальный флаг для получения списка уникальных идентификаторов счетчиков производительности, доступных на vCenter Server (нужно указать -1 в качестве аргумента для получения списка). Далее можно использовать один из полученных идентификаторов для вывода соответствующей метрики для кластера.
Возможности скрипта vCenter Cluster Performance Tool:
Сбор всех данных в указанном интервале, которые доступны на каждом хосте заданного кластера.
Простой способ запуска сценария.
Данные сохраняются в файл CSV, которые можно подставить в любое средство визуализации.
Также генерируется график в формате картинки PNG (как показано выше).
Для работы скрипта потребуется VMware vCenter Server 5.0 или более поздний, а также Microsoft Chart Controls для Microsoft .NET Framework 3.5. Скачать vCenter Cluster Performance Tool можно по этой ссылке.
Некоторые из вас помнят, что в VMware vSphere 6.5 одной из новых возможностей гипервизора ESXi 6.5 стала функция его безопасной загрузки (Secure Boot). Об этом мы уже упоминали в посте с видеороликами о новых возможностях vSphere 6.5:
Суть механизма безопасной загрузки в vSphere 6.5 заключается в том, что загрузка подписанного кода гипервизора ESXi контролируется со стороны UEFI firmware, а также не разрешается исполнение неподписанных пакетов.
UEFI (Unified Extensible Firmware Interface) - это замена традиционному BIOS в серверах и настольных ПК. Механизм Secure Boot - это один из "протоколов" UEFI, который предоставляет возможности контроля загрузки подписанного кода за счет хранения цифровых сертификатов, которые хранятся в микрокоде (firmware) компьютера (signature database). Это все позволяет убедиться в том, что некий root kit не будет присутствовать в составе загружаемых компонентов и не предоставит доступ злоумышленнику на самом низком уровне.
Большинство UEFI содержит набор сертификатов по умолчанию типа x509 Microsoft UEFI Public CA, а также позволяет устанавливать собственные сертификаты дополнительно. Надо отметить, что эти сертификаты поставляются производителем серверов и обновляются вместе с его микрокодом.
Для обеспечения безопасной загрузки используются следующие компоненты:
Загрузчик ESXi (boot loader) - он убеждается в том, что цифровая сигнатура кода не была изменена. Загрузчик подписан сертификатом Microsoft UEFI Public CA. Он также содержит VMware public key, с помощью которого проверяются компоненты VM Kernel, Secure Boot Verifier, а также пакеты VIB.
Ядро VM Kernel - это также подписанная часть кода. Первое, что делает VM Kernel, это запускает Secure Boot Verifier.
Secure Boot Verifier - он также хранит VMware public key и проверяет аутентичность всех VIB-пакетов, которые загружаются во время загрузки ESXi.
VIB-пакеты (vSphere Installation Bundles) - эти пакеты, помимо реализуемых ими сервисов, содержат файл XML descriptor и файл цифровой подписи (digital signature file). Во время загрузки ESXi в памяти создается "карта" содержимого каждого из VIB-пакетов, соответственно не требуется проверять каждый из его файлов, а достаточно проверить подпись пакета целиком (это быстрее работает).
Вот как выглядит процесс загрузки хоста ESXi с точки зрения Secure Boot:
Включение питания.
UEFI Firmware валидирует загрузчик ESXi Boot Loader на предмет соответствия сертификату Microsoft внутри микрокода UEFI.
ESXi Boot Loader валидирует компонент VM Kernel на предмет соответствия сертификату в Boot Loader.
VM Kernel запускает компонент Secure Boot Verifier.
Secure Boot Verifier валидирует каждый VIB-пакет на соответствие сертификату VMware, который находится в хранилище Secure Boot Verifier.
Запускаются необходимые сервисы управления (DCUI, hostd и т.п.).
При апгрейде VMware ESXi прошлых версий с помощью ESXCLI происходит обновление сигнатур VIB-пакетов, но Boot Loader остается прежним, поэтому когда вы включите Secure Boot - возникнет ошибка. Как следствие - нужно будет переустановить ESXi.
Если вы обновляете ESXi из ISO-образа, то для некоторых старых VIB-пакетов сигнатуры могут не обновиться (например, кастомные драйвера, которые вы устанавливали отдельно), что приведет к неудаче при безопасной загрузке. То есть для нормального обновления из ISO нужно, чтобы все VIB-пакеты в этом образе обновили все предыдущие VIB. Надо отметить, что VIB-пакеты уровня Community supported не поддерживаются для безопасной загрузки (так как они не подписаны).
В составе VMware vSphere 6.5 есть специальный скрипт, который проверяет возможность безопасного апгрейда прошлой версии платформы.
Сначала надо проверить, что серверы поддерживают UEFI secure boot. Далее надо убедиться, что все ваши VIB-пакеты имеют хотя бы уровень Partner Supported, и у вас нет Community Supported пакетов.
Если вы обновили хост на ESXi 6.5, то можно выполнить следующий скрипт для проверки возможности включения Secure Boot:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Результатом будет строчка "Secure Boot can be enabled" или "Secure boot CANNOT be enabled".
Если вы включите Secure Boot в микрокоде сервера, но у вас есть неподписанные пакеты, то при загрузке сервера вы увидите розовый экран и сообщение о том, что нельзя проверить подписи VIB-пакетов:
Чтобы выйти из этой ситуации, надо выключить безопасную загрузку, удалить неподписанные VIB-пакеты и снова включить ее.
Еще одна фишка включенной функции Secure Boot - это то, что вы не сможете установить неподписанные VIB-пакеты с опцией force подобным образом:
Если говорить о модуле TPM, то он тут не участвует, и мало того - TPM 2.0 вообще не поддерживается со стороны VMware vSphere 6.5.
Ну и последнее. Если вы хотите использовать Secure Boot вместе с механизмом vSphere Auto Deploy, то вы должны добавить сертификат VMware в список UEFI firmware whitelist (DB). Это требуется потому, что только ESXi Boot Loader подписан сертификатом Microsoft, а часть кода PXE-загрузчика, которая грузится до Boot Loader, подписана сертификатом VMware. Более подробно об этом написано в KB 2148532.
Хорошим дополнением к этому будет видео ниже, в котором в течение 80 минут рассказывается о тонкостях возможностей продукта с технической стороны (правда там нет обзора фич последних версий 6.5/6.6).
Видео предназначено для тех, кто хочет понять, как работает кластер vSAN, что такое Disk Object, Storage Policies, как работает флэш-кэш, растянутый кластер и другие штуки. Если вас не раздражает индусский английский, то видео вполне интересное.
Ну а вот еще несколько видео о последнем vSAN 6.6 и его новых возможностях, которые также могут быть полезными:
Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:
Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.
Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):
А что для случая, если машины Witness VM разместить на разных площадках?
Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.
Поэтому нельзя перекрестно конфигурировать Witness VM для двух растянутых кластеров на двух площадках - нужно использовать третью площадку, чтобы кворум обеспечивался при любом виде сбоя на уровне одного из сайтов.
Начиная с VMware vSphere 6.0, компания VMware предлагает администраторам очень удобный механизм для назначения прав доступа на самом высоком уровне при наличии нескольких серверов VMware vCenter - глобальные пермиссии (global permissions).
Для тех, кто использует режим vCenter Enhanced Linked Mode (ELM) с несколькими географически разделенными площадками и разнородными инфраструктурами, глобальные пермиссии - это отличное решение, так как они создаются один раз, после чего распространяются и (что самое главное) поддерживаются в согласованном состоянии на всех серверах vCenter связанной инфраструктуры в рамках одного домена Single Sign-On (SSO).
Вильям Лам, известный своими сценариями для автоматизации инфраструктуры vSphere, написал удобный скрипт GlobalPermissions.ps1, позволяющий добавлять и удалять глобальные пермиссии. Он содержит методы New-GlobalPermission и Remove-GlobalPermission, для которых можно задавать следующие параметры:
vc_server - хост сервера vCenter
vc_username - имя пользователя vCenter
vc_password - пароль пользователя vCenter
vc_user - пользователь vCenter, которому будут назначаться пермиссии
vc_role_id - идентификатор Role ID, который связан с ролью vSphere на данном vCenter Server
propagate - значение true или false для распространения пермиссий вниз по уровням иерархии
Чтобы получить параметр vc_role_id, нужно соединиться с vCenter Server и указать имя роли, выполнив сниппет ниже. В данном примере мы получаем ID административной роли с именем Admin:
(Get-VIRole -Name Admin).ExtensionData.RoleId
Вот пример создания новой глобальной пермиссии для одного из пользователей: